(レポート) AWS Premier Night 2 in Osaka #awspremier

はじめに

2016年9月16日に大阪で開催されたAWS Premier Night #2 in Osakaのレポートです。会場はエムオーテックス新大阪ビル。すごく綺麗なイベント会場です。エムオーテックス様ありがとうございました！

このイベントについて

AWS プレミアコンサルティングパートナーである、クラウドパック、クラスメソッド、サーバーワークス(※五十音順です)の3社で開催する勉強会です。テーマはズバリAWS！最新情報、デモンストレーション、事例、ここでしか聞けないような濃厚な技術ネタなどなど盛りだくさんの内容です。

レポート

IPv6 on AWS

スピーカーはクラスメソッド株式会社の大瀧 隆太。本人もブログを書いています(AWS Premier Night #2 in OsakaでIPv6 on AWSのお話をしました #awspremier)

質問

・IPv6で通信したことがある人？4割。 ・本番環境でIPv6を構成したことがある人？0。

IPv6は今年21周年

・だが、本番で使われるような状況にない。 ・現在のAWSでのIPv6サポート状況。 ・IPv6対応AWSサービスの定義。 サービスから割り当てられるリソース、または共有サービスのエンドポイントがIPv6レコードを持っていること。 ・対応しているもの。 ・EC2 Classic ・ELB(Classic EC2との組み合わせのみ)、かなり限定的。 ・Amazon S3、最近使えるようになった。エンドポイントにdualstack.を付与すれば使える。 ・Static Website Hostingでは使えない。 ・AWS IoT、MQTTSで使える。 ・たくさんあるサービスの中で対応しているのはこれだけ。 ・なぜか？IPv6インターネット自体がまだ主流じゃないから。 ・特にコンテンツ提供側はまだまだこれから。 ・v6インターネットはv4インターネットとは別物。 ・クライアント/サーバーそれぞれがv6に対応していないとv6で通信できない。 ・クライアント側は対応が進んでいる。 ・クライアントのデュアルスタック対応はほぼ完了。 ・ISPも現状オプションとしてIPv6対応を提供している。 ・IIJだと標準でIPv6アドレスを振ってくれる。 ・デモ。curlで接続すると、IPv6でアクセスしていることがわかる。 ・クライアントからサーバーへのアクセスはドメイン名でアクセスするのが普通なので、IPv6であることを意識することはない。 ・サーバー側は対応が進んでいない、全然聞かない。 ・IPv4インターネットが主流なので、困らない。積極的に対応しない。 ・v6インターネットの普及が進まない。 ・セキュリティ対策やパフォーマンス対策と比べてモチベーションがわかない。 ・IPレイヤーの切り替えは影響が大きい。 ・IPv6の足音が大きくなってきた。 ・Apple App StoreのIPv6対応義務化。 ・今後もぼちぼち出てくるのではないか。Googleなどのビッグプレイヤー？あるいは行政からのアクション。 ・IPv6対応はいつやるのか？ ・もうちょっと様子見 ・とはいえいつビッグプレイヤーからお達しが来るか分からない。 ・準備をしておく必要がある。

IPv6の準備

・サーバー側でのIPv6対応。 ・接続点の対応。 ・現在のAWSの利用では、EC2を直接外部公開するより、LBやCDN経由で公開することが多い。 ・LBやCDNといった接続点でIPv6に対応する。 ・接続点で対応すれば、EC2側を全部IPv6にする必要はないかも知れない。 ・アプリケーションでの対応 ・IPv6化することでアクセスログが肥大化するので注意。 ・クライアント側 ・デュアルスタック対応の場合、片方の通信がダメならフォールバックする。 ・IPv6の動作確認をするときにIPv4で通信してしまって邪魔になる。 ・DNSとの連携。DNS周りは気にしなくてはいけないことが多い。 ・ISPのIPv6オプションを使ったり、IPv6が使えるVPSを利用したり。

AWSのIPv6サービス対応

・LB、CDNSの対応に期待。 ・Route 53の対応も期待。 ・VPCは？ ・接続点がv6対応すればVPCはv4のままでもいける。 ・VPN/DirectConnectでIPv6のオンプレミスネットワークと繋ぐ場合は問題になる。 ・NTT光接続網はIPv6。 ・NTT東日本のクラウドゲートウェイ アプリパッケージ。

まとめ

・ELBとCloudFrontがIPv6対応したらぼちぼち考えるタイミング。 ・フルIPv6が必要なわけではない。要件によって変える。 ・動作確認が大変。ご利用は計画的に。

Terraform実践入門

スピーカーはクラスメソッド株式会社の中山 幸治。資料はこちら。

今日はCloudFormationの話はしない

・宗教的な話になってしまう。 ・できることは大体同じ。 ・好きなほうを使えば良い。

Terraformとは

・Hashicorpを中心に開発されているOSSのインフラ構成ツール。 ・AWS/GCP/Azureなど、主要なクラウドサービスに対応。 ・リソースまたはデータソースとしてサービスを構成。 ・変数を使って定義。文字列、リスト、マップが利用可能。 ・様々な歌数が用意されている。 ・ループも可能。 ・Terraformのファイル ・インフラのあるべき状態をtfファイルに記述。 ・実際の状態がtfstateファイルに書き込まれる。 ・中身はJSON。 ・Terraformの実行方法 ・コマンドラインから実行。 ・planで変更内容の確認、applyで実行。 ・palnの結果とapplyの結果を確認することで差分を確認できる。

ベストプラクティス

・tfファイルの分離 ・Terraformはカレントディレクトリのtfファイルを全部実行する。 ・リソースごとにtfファイルを分離してしまうと管理が楽。 ・リソースの依存関係はTerraformが自動的に解決してくれる。 ・モジュールを利用 ・モジュール(関数)を使い回すことで環境が違ってもコードが使いまわせるように。 ・variables.tfに環境ごとの差異を吸収。 ・本番環境と検証環境の差異はモジュールで定義する。 ・Pull Requestベースでインフラを開発する。 ・既存のAWS環境のリソースをコード化。 ・Terraformのimport機能かterraforming。

EC2の自律稼働を目指して（仮）

スピーカーはcloudpackの村主 壮悟さん。

結論。SSHはしないほうがいい(NoSSH論)

・なぜ運用中にSSHをするのか。 ・設定変更、アプリのデプロイ、障害の調査... ・障害調査でよくやること。 ・サーバに対してSSH。 ・リソース状況の確認。 ・それらの作業をやるときに一番恐ろしいのはオペミス。 ・調査の精度や速さは個人に依存。勘や匂いに依存する。 ・オペミスは再発防止策が難しい。知識不足や経験不足、手順ミス、環境確認漏れ... ・そもそもログインするからオペミスが発生する。ログインしなければ良い。

ログインして確認しているものを洗い出し

・リソースの確認、ログの確認、その他... ・リソースの確認はモニタリングツールで収集。 ・ログはログ収集基盤と分析ツールで見える化。 ・メトリクス系→CloudWatch、Datadog、Munin、Grafana... ・ログ系→CloudWatch Logs、Papertrail、Fluentd... ・何でも収集すると解析が困難、最適なものを必要最小限集める。 ・そうすればログインを無くせるのはないか。

障害対応

・サービスの起動停止。 ・サービス起動順番が依存していたり... ・システムが増えると手順書が増える、管理も大変、どれが最新だかわからない... ・システムごとに手順書がバラバラ ・手順書の更新漏れ ・どれが最新か分からない ・全部インタンス再起動でええやん。 ・OS起動時はサービスは必ず順番通りに上がってくるはず。 ・復旧手順を簡素することで手順書が簡素化される。 ・人が手動で操作するより機械にやらせたほうが早い。

まとめ

・SSHをやめるのは人類には早過ぎる→CTO「なら人類やめちゃおうかな」 ・変更時、障害時、復旧時→SSHをしない。 ・障害時の調査は必要→EC2のPaaSが欲しい。

Amazon Elastic MapReduce - クラウドでHadoopをもっと使いやすく

スピーカーは株式会社サーバーワークスの柏尾 尚久さん。

Hadoopとは

・HDFS ... 複数のサーバで一つのファイルシステムに見せる ・クラアイントからファイルを置くと複数のサーバに分割して配置される ・ディスクI/Oを並列化してスループットを高める ・複製されているのでサーバが故障してもデータが無くならない ・MapReduce ... 分散処理フレームワーク。データを分類して、keyごとにvalueを整理。 ・作法に従ってプログラムを作れば勝手に処理してくれる。 ・サーバを追加することで処理性能が上がる。 ・スケールアウト可能なアーキテクチャ、大量のデータを処理保存できる。 ・バッチ処理、データ加工に向いている。 ・OSSなので周辺ツールも充実 ・データ連携(Sqoop/Fluentd/Flume) ・データ処理(Hive/Impala/Presto) ・Apache Spark ・Haddopの基盤上で、サーバのメモリ上で処理を動かす

オンプレHadoopでの困りごと

・ハードウェアの故障 ・OSやネットワークのチューニング ・ソフトウェアの組み合わせと構成 ・ジョブ実行で処理時間のバッティング、使ってない時間が勿体無い

Amazon Elastic MapReduce

・ハードウェアの管理不要 ・OS/ネットワークは最適化済み ・使いたいときだけ起動 ・EMRFS(S3をHDFSぽく使う) ・Hadoopクラスタとストレージを分ける ・KinesisのデータをEMRで処理 ・チュートリアルが用意されている

EMRのまとめ

・ハードウェアの調達・保守・運用が不要 ・ソフトも自動でインストール ・必要なときに必要なだけ使える。 ・クラウドでHadoopをもっと便利に。

運用自動化の取り組み

スピーカーはcloudpackの青池 利昭さん。

cloudpackの状況

・サーバの増加→インシデントの増加→Opsの負担増加 ・インシデントが漏れない仕組み、発生状況を可視化する仕組み、作業を補助する仕組み ・インシデント管理→Pagerdutyを使っている ・インシデントが漏れない仕組み ・Pagerdutyを導入し、Nagios/sensuからメールとPagerdutyにプッシュして監視を強化 ・Elasticsearch Serviceを使ってPagerdutyとメールの差異を確認 ・お客様との情報共有にBacklogを利用 ・メンバーが休みをとっているとBacklogのチケットにすぐに対応できない ・Backlogからの通知をLambda経由でSlackに通知 ・インシデントの可視化 ・Pagerdutyでは組み込まれた観点でしか分析ができない ・可視化基盤としてKibanaで分析 ・自分たちで見たい観点で分析可能に ・インシデントに対する作業の補助 ・サーバの情報を自動的に取得 ・PagerdutyからwebhookでAPI Gateway + Lambdaをキック ・管理用EC2サーバから顧客サーバに自動的にSSHログインし情報を自動的に取得 ・インシデントのBacklog課題自動登録 ・PagerdutyからAPI Gateway + LambdaをキックしてBacklogに課題を自動的に登録 ・通知の一元化 ・PagerdutyからwebhookでAPI Gateway + Lambdaをキック、AWSのサービスから通知 ・URL監視 ・Pagerdutyでインシデントが発生したらWebサイトにアクセスして画面キャプチャとレスポンスコードを記録

Pagerdutyについて

・使っている機能。WebhookとWebAPI。 ・Webhook。 ・triggered(インシデント発生)が再通知されたり、順番がずれたりする。 ・開発元。一回以上の通知を保証するため、こういう動きになる。 ・Webhookのステート管理を自前で構築。 ・5秒ルール。投げて戻って来るまで5秒以内である必要がある。 ・処理によっては10秒以上かかるケースがある。 ・処理系統を分離して時間を短く。 ・200が帰ってこない場合は50秒後リトライ。 ・7回リトライするので最大8回処理実行。 ・8回実行してダメなら処理停止。 ・WebAPI ・現在のAPIはv2。以前のv1は処理が遅かった。v2のほうが性能が良い。 ・APIキー単位に1分間に2000回のアクセス制限がある。 ・アクセス制限時は専用のレスポンスコードになる。 ・Pagerdutyに一番近いリージョンはus-west-2。 ・Pagerdutyのサポートはとても優しい。言葉の壁はあってもスムーズ。

まとめ

・用途に応じてAPIキーを使い分ける。 ・Webhookのステートは自分たちで管理。 ・オレゴンリージョンを使ってPagerdutyに近い場所で使う。 ・処理は非同期で行う。

Amazon Elasticsearch Serviceのおもしろい使い方

スピーカーは株式会社サーバーワークスの小林 孝剛さん。

検索の歴史

・1990年、世界で最初の検索エンジンArchieがスタート。 ・FTPサーバ内のファイルを検索するだけのもの。 ・検索エンジンサービスの移り変わり。 ・オープンソースの検索エンジンの登場。 ・Apache Lucene/Solr ・Elasticsearch ・検索エンジンの役割 ・知りたい情報へのアクセス。最近は大抵のサービスで検索が組み込まれている。 ・集まった情報を解析して欲しいように提供する。

Amazon Elasticsearch Service

・検索エンジンのマネージドサービス。構築も簡単、従量課金。 ・検索エンジン、ログ連携、可視化、日本語対応、管理が容易。

おもしろい使い方

・よくあるシーン。ログをKibanaで可視化。 ・検索エンジンの部分をご紹介。 ・More Like This Query。類似文章検索。 ・同じ単語を多く含んでいる文章は似ていると判別。 ・Indexでterm_vectorsをyesに設定する。 ・デモ。Developers.IOをElasticsearchに入れてMore like this queryしてみる。

まとめ

・検索エンジンはまだまだ枯れていない。これからも進化する。 ・Amazon ESはぽちぽちクリックするだけですぐ使える。 ・類似予測も簡単に出来る。

さいごに

今回もとても濃いセッション満載でした。またやりたいですね！